1. Technical Field of the Invention
The invention relates to the field of computer programming languages, methodologies and systems and more particularly, to a system and method for reducing the interdependence between modular software units and facilitating the dynamic replacement or hot-swapping of software modules at run-time in a real-time environment, such as a telecommunications environment.
2. Description of Related Art
This patent application concerns the development and maintenance of large software systems. It has been found desirable to have the ability to extend or modify a system so as to cope with new or changed requirements. It has further been found desirable to find techniques for making such changes both simply and selectively. Consequently, an ideal software development environment should permit much of the software used in an old system to be reused or be combined into a new system with only slight modifications. In some application areas such as the telecommunications, it has also been found desirable that system modifications be possible during run time, i.e., to be made dynamically in a live system. Such dynamic system modification is sometimes referred as xe2x80x9chot-swappingxe2x80x9dxe2x80x94a term commonly used in the field of computer hardware.
In order to limit the cascading effect of changes and to simplify the reuse and/or modification of different parts of a large software system, it has become common to partition the software into modules on the basis of some general design principles that offer such benefits. It should be emphasized that ideally the different software modules should be as independent of each other as possible so that a change in one module or the replacement of another does not result in or require changes to a great number of other modules.
The decoupling of software modules (variously referred to in the art as parts, components, objects or processes) is currently solved by a two-step process. First, by requiring that an interface be declared that defines what a module type may provide to other module types, and sometimes also defining the functions and data that a module may use from other modules. Next, such interface information is used to statically link the different modules into a system. This technique can prevent ordinary users of a module from directly using knowledge about the internal implementation of a software module in undesirable ways.
Class 5 telecommunications switches, such as ATandT""s 5ESS system or Ericsson""s AXE-10 system, comprise complex telecommunication hardware and software. The software architecture of Ericsson""s AXE-10 system requires each block or module to have a Signal Sending Table (SST) to decouple it from other blocks or modules. The basic purpose of the Signal Sending Table used in AXE-10 is to provide linking information for signals sent from a module, specifying the receiving module the signals are intended to be sent to. The signals sent are used to trigger the execution of program code implementing the function associated with the signal but are typically not directly linked to the entry position for such code. Instead the linking is done indirectly via a Signal Distribution Table (SDT), for the common input port of the block. The entry position in this SDT is called the Local Signal Number (LSN). One can use a linker to find the LSN of a receiving block and provide this information to the SST of the sending block.
The AXE-10 software architecture also includes support for a concept referred to as xe2x80x9cmultiple signalsxe2x80x9d wherein the same signal is sent to multiple receiving blocks and where the receiver that is to act on the signal is specified at run-time. In this case one needs to find the smallest possible LSN that fits all receiving blocks (so as to avoid wasting a large block of memory space for the SDT). This reduces to a difficult optimization problem that should be avoided if possible.
As described in U.S. Pat. Ser. No. 5,297,285 entitled SYSTEM FOR DYNAMICALLY LINKING MODULAR PORTIONS OF COMPUTER SOFTWARE issued to Anders ABRAHAMSSON and Lars HOLMQVIST, one way to improve this software architecture is by complementing the Signal Sending Table and Signal Distribution Table of the various different modules with a Global Signal Distribution Table (GSDT). This simplifies the problems associated with the dynamic linking of software modules. In such a case, the sending block can use a Global Signal Number (GSN) in conjunction with the block number of the receiving block to find the appropriate LSN for that receiving block. FIG. 1 is a diagrammatic representation of the manner in which modular software blocks are dynamically linked in accordance with the system of this Ericsson patent.
The system and method disclosed in the above-identified Ericsson patent can be extended or generalized as to cover the case where a symbolic block number is replaced by an actual block number. More details about this technique can be obtained by reference to this U.S. Pat. Ser. No. 5,297,285.
Another U.S. Pat. Ser. No. 5,339,430 entitled SYSTEM FOR DYNAMIC RUN-TIME BINDING OF SOFTWARE MODULES IN A COMPUTER SYSTEM issued to Kenneth LUNDIN and Ulf MARKSTRxc3x96M describes a technique for object decoupling and dynamic relinking of object-oriented software modules using abstract language-independent interface specifications supported by compilation techniques and an address trader (which is functionally equivalent to a global address table) that is built into the kernel of the operating system.
Yet another U.S. Pat. Ser. No. 5,410,703, entitled SYSTEM FOR CHANGING SOFTWARE DURING COMPUTER OPERATION issued to Rickard NILSSON, Ulf MARKSTRxc3x96M and Leif KLxc3x96FVER describes the use of an addressing mechanism that allows two references, one to an old module or object and the other to a new module or object. This patent also describes a mechanism for relating and maintaining the state of both an old as well as a new module during the updating phase in an object-oriented system. FIG. 2 is a flow chart illustrating the process of changing software during run-time in accordance with the system of this Ericsson patent. However, it should be noted that the term xe2x80x9cmodulexe2x80x9d as used in this reference appears to refer to a software reload unit or replacement unit, and has thus a somewhat different meaning from the term as used in the present patent application.
In theory, program entities invoking a module (which may be other modules) can be restricted from straying beyond a defined interface and from using knowledge about the implementation of a module. However, different modules are often designed by software engineers who have knowledge about the existence and internal architecture of other related modules. They may use their information in ways that can make future changes to the system complex.
There is a fundamental conflict in designing modular software systems. On the one hand, one would like to modularize the design of complex software systems by partitioning the application domain and then using the set of software modules as building blocks in crafting a solution. This requires that the various software modules complement each other and work well in combination.
On the other hand, it is also desirable to provide each module with the least amount of information about the internal implementational details of other modules. While it is important to provide each module with abstract or essential knowledge about other software modules in order to permit a module to make use of other modules, it is also desirable to restrict access to detailed internal information about a module (e.g., address information regarding a specific instance of a module type) from other modules.
Current approaches for addressing this problem have principally concentrated on techniques for encapsulating and protecting the module internals. However, these approaches do not prevent inter-dependencies between modules from arising, which in turn may make system changes difficult to implement without the modification of multiple modules. Thus there is a need for techniques that can help decouple modules by restricting use of knowledge about other modules other than that specified in an interface definition. As noted earlier, this issue has been partially addressed by U.S. Pat. Ser. Nos. 5,297,285 and 5,339,430 identified above, albeit by techniques that are different from those described and discussed herein.
There is also a need for software programming environments that support dynamic modifications to or configuration changes of software systems using new or modified modules while the system is running. As noted earlier, this issue has been partially addressed in U.S. Pat. Ser. No. 5,410,703 identified above, albeit again by different methods than those described and discussed herein.
Since telecommunications systems are expected to not have any downtime, on-going calls or other similar services need to be continuously kept operational. As a result, the transition from an old software system to a new one cannot be instantaneous. Consequently, linking mechanisms are needed to relate the software to both ongoing (or old) calls as well as to new calls (or services that may be separated into different parts). Furthermore, some information needs to be maintained and updated in both the old as well as the new software parts during the relinking process. In some instances, it may be desirable to divide this relinking process into multiple phases.
Traditional Telecommunication Software Development:
The traditional approach to telecommunication software development has been function-oriented. The function-oriented analysis was (and is) based on a top-down (or black box) view of system requirements. In real-time applications such as telecommunications, such an analysis focuses on the functions or services provided to external clients and is implemented as processes that are distributed over a telecommunications network.
In contrast, software engineers often focus on algorithm control structures, on data structures and on data transformation methods. In the function-oriented approach, as understood by skilled software engineers, data is usually considered as being global, although in some instances data maybe encapsulated. Consequently every change in the representational format of a datum immediately feeds back into the design of every function that manipulates that datum.
This disadvantage can be ameliorated somewhat, by manipulating the data indirectly, i.e., by manipulating the data symbolically or by using a specialized interface function that serves as a filter. The use of such interface functions can also permit modification of the representational format of the data and can be used to obtain an abstract view of the data. Thus, choice of a proper software architecture model can avoid or eliminate many of the problems that are often associated with the function-oriented approach to software design.
The function-oriented approach is most commonly used nowadays to manipulate information contained in databases. Each database management software program often uses an abstract information model that isolates the data representation from its manipulation. However, the internal structure of the database is not accessible to an end-user who invokes standard functions to manipulate the information contained in the database.
In contrast to the function-oriented approach which focuses on functions that transform or manipulate external or global data, the object-oriented approach advocates an inverted, more structure-oriented or implementation-oriented view of the world, that focuses on objects that in turn are represented by data and applicable functions. This approach, which is achieved by separating the function-naming parts of messages (including their intended interpretation) from the implementations of the functions, makes it possible to encapsulate and hide the data representations that are used in a specific implementation. Thus, this approach requires both the message-names as well as their meaning (which constitute the communications means between objects) to have stable definitions.
The encapsulation of certain information in distinct system entities that communicate amongst each other through signals has been a common approach amongst many telecommunications software designers and programmers. This approach has been used in order to handle system components in a coherent way that is independent of their physical location and implementation. In this telecommunications software engineering paradigm, a function at the system-level is implemented by the interworking of different system components each containing some of the necessary parts of the function being implemented, including the related data.
More details about the use of object-oriented approaches to developing software for telecommunications applications can be found in U.S. patent application Ser. No. 08/723,107, entitled SYSTEM AND METHOD FOR REDUCING COUPLING IN AN OBJECT-ORIENTED PROGRAMMING ENVIRONMENT. 
The current object-oriented paradigm suffers from several problems. The first of these is the likelihood of excessive coupling between objects. Such excessive coupling often arises due to direct references by some objects to other serving objects via messages as well as via class structures and/or object structures. Another problem with the present paradigm is the lack of a deterministic solution for minimizing the amount of coupling between objects and/or subsystems and the lack of a suitable decomposition technique for the same purpose.
It should be emphasized that much of the issues detailed below relative to the problems of traditional (single-port) object-oriented software design are equally applicable to modular software development. Thus, for example, many of the problems reportedly associated with the use of present object-oriented software development techniques may be attributable to the use of objects having only a single (input) port. As detailed in U.S. patent application Ser. No. 08/723,107, entitled SYSTEM AND METHOD FOR REDUCING COUPLING IN AN OBJECT-ORIENTED PROGRAMMING ENVIRONMENT, the current object-oriented programming paradigm may be improved upon by using objects that have both an input port as well as an output port. Similar problem have also been observed with modular software development. Those of ordinary skill in the art would understand that an xe2x80x9cobjectxe2x80x9d is a lower-level programming construct than a xe2x80x9cmodule.xe2x80x9d
A central problem with the present object-oriented paradigm is that objects are well-protected only from external misuse. Currently some measure of decoupling can be achieved by using a message dispatch function that works as an input port for each object as shown in FIG. 3. As noted earlier, it may be possible to extend this technique from the object-level to the module-level.
FIG. 3 shows an object o1 300 having an input port p1, 301 and containing two functions (or methods) f1 311 and f2 312 that modify, manipulate, or transform two attribute values, v1 321 and v2 322. The role of the input port p1 301 is to decouple the accesses (or invocations) of the functions f1 311 and f2 312 from their implementations by using an externally published function-name in the invoking message.
Thus the input port p1 301 serves as an attribute-value or function-name dispatch function. However, this technique of decoupling does not prevent problems arising from an object being dependent on other objects that it invokes. Thus, changes to object o1 300 may influence all other objects invoked by it since each object is often linked to many other objects as shown in FIG. 4.
FIG. 4 illustrates the strong coupling between objects that arise from message links between various objects. Four objects o1 401, o2 402, o3 403 and o4 404 are shown in FIG. 4. Thus, the invocations of object o1 401 may cause its functions f11 411, f12 412 and f13 413 to invoke in turn objects o2 402, o3 403 and o4 404 as shown in the figure. Likewise, the invocation of object o2 402 causes its functions f21 421 and f22 422 to invoke inter alia, object o4 404. Likewise the invocation of object o3 403 causes its functions f31 431, f32 432 and f33 433 to invoke inter alia, object o4 404.
Analogously, as shown in FIG. 4, the invocation of object o4 404 causes its functions f41 441 and f42 442 to invoke objects o2 402 and o3 403. Thus changes in the internal structure of object o1 401 will impact upon the operation of objects o2 402, o3 403 and o4 404.
It has been found that strong coupling between modules lacking an output port poses the same kind of problem. This illustrates an important structuring guideline that can be used to decrease the coupling between objects/modules and improve the operation of object-oriented or modular software programs, namely, that it is important to isolate elements that change frequently from other elements that remain relatively stable over long periods of time.
As can be seen from the above description, current attempts to standardize the design and development of computer software have focused only on high-level standardization efforts. However, in order to provide a design base that can respond to market needs and economic constraints, software systems and their components need to be flexible and reusable. Consequently, it has been found desirable that software architectures support inter-operability, modifiability and implementation-independence over long periods of time.
A good system architecture therefore needs to be based on a definitive conceptual design that incorporates knowledge about the requirements that will be imposed upon the system. Consequently, important elements of the architecture including paradigms, interfaces, naming rules, messaging schemes, addressing schemes, key components, structure, layers, function decomposition principles, design rules and support tools must be selected in advance in such a manner as to maximize their consistency, simplicity, uniformity and orthogonality.
Piece-meal improvement of an existing architecture cannot always suffice, as an existing architecture may lack a consistent architecture or framework of system interfaces; different applications might be incompatible; industry standards might not have been adhered to; or the accumulated sum of new customer requirements might necessitate the design and development of a new software architecture model.
In order to improve the architecture of a software system, one first needs to understand the problems that arise from the present object-oriented paradigm. Knowledge of the underlying problems can help make new designs more modifiable, inter-operable and implementation-independent.
Therefore it is a primary object of the present invention to permit the decoupling amongst the software modules in a telecommunications environment. It is a further object of the present invention to permit the easy and dynamic updating of software modules in a running system.
A system and method for reducing the coupling between modules of a software application program in a modular telecommunications software programing environment is described. The programming environment comprises a computer system containing a processing unit, a memory unit, an I/O (input/output) unit and an operating system.
In one aspect of the present invention, the technique starts with the creation of functionally-distinct software program modules. When a software module is revised to add new features, both versions of the software module are stored. Each of the modules that use the services of other modules has at least two logical output ports, with each of the two logical output ports serving to route data to the appropriate version of the other module.
It should be noted that the set of two or more logical output ports may be implemented as a single physical output port. Further, the various output ports could be masked to appear as a unitary symbolic destination port to a system programmer. A selected group of two or more modules is linked into a telecommunications application program. The software application program is executed on the computer system, by processing all invocations of non-local references in each module through the appropriate output port of the module.
In another aspect of the present invention, a method for facilitating the reuse of modular software units is described. The technique begins with the grouping of software modules of the telecommunications application program into Access Modules, Service Modules and Resource Modules. Access Modules are responsible for managing the Access Individuals while Service Modules are responsible for managing the Service Individuals. Likewise, the Resource Module is responsible for managing the Resource Individuals.
A select group of modules that may be combined into a telecommunications application program are next identified. Each module that invokes other modules is provided with specific address information about the other modules no earlier than system building time, creating corresponding module instances. The instances of the selected group of modules are then lined into a telecommunications software application program. The software application program is then executed on the computer system, by processing all invocations of non-local references in a module through the Access Module.
In yet another aspect of the present invention, a system and method for the selective replacement, testing and activation of modular software units in a telecommunications application program is described. The technique begins with the creation of functionally-distinct software program modules. When a software module is revised to add new features, both versions of the software module are stored. Each of the modules that use the services of other modules has at least two logical output ports, withxe2x80x94each output port serving to route data to the appropriate version of the other module.
The software modules of the telecommunications application program are then grouped into Access Modules, Service Modules and Resource Modules. Access Modules are responsible for managing the Access Individuals while Service Modules are responsible for managing the Service Individuals. Likewise, the Resource Module is responsible for managing the Resource Individuals.
Each new service need identified by an Access Module is assigned a unique Service Identity (SI). A globally unique Selection Variable (SV) is then specified to indicate when the telecommunications application program is to make the transition from using the first version of the second module to using the second version of the second module. The Service Identity is then compared with the Selection Variable. If the Service Identity is greater than or equal to the Selection Variable, the modules of the telecommunications application program are relinked by replacing references to the first version of the second module with references to the second version of the second module. The software application program is then executed on the computer system.